Configuring Manifest Entries, SDK Versions, and App Permissions

Course: Android App Development

Topic: Configuring Manifest Entries, SDK Versions, and App Permissions

Course Link: Android App Development Course

Demo Registration: Register for a Course Demo

JustAcademy Website: Visit JustAcademy

1. Introduction

Every Android application needs configuration that tells Android Studio, Gradle, the Android operating system, and app distribution platforms how the application should be built, installed, and executed. Three important areas of this configuration are the Android manifest, SDK version settings, and application permissions.

The AndroidManifest.xml file describes essential information about an application, including its components, permissions, supported features, and certain configuration options. SDK version settings define which Android versions an app supports and which platform behavior it is designed to target. Permissions determine whether the application can access protected device features or sensitive user information.

Correct configuration helps developers improve compatibility, protect user privacy, prevent installation problems, and prepare applications for testing and release.

2. Learning Objectives

• Understand the purpose and structure of the Android manifest file.
• Learn important manifest elements and attributes.
• Understand the difference between compile SDK, minimum SDK, and target SDK.
• Configure SDK versions in a Gradle build file.
• Declare activities, services, receivers, and other application components.
• Understand normal, dangerous, and special permission categories.
• Declare permissions and request runtime permissions where required.
• Configure internet, camera, location, and notification permissions appropriately.
• Identify common manifest and permission errors.
• Apply best practices for Android application configuration and security.

3. What Is AndroidManifest.xml?

AndroidManifest.xml is a configuration file included in an Android application's source set. It provides essential information to Android build tools, the operating system, and distribution services.

In a typical Android application module, the file is located at:

app/src/main/AndroidManifest.xml

The manifest can declare:

• Application components such as activities, services, broadcast receivers, and content providers.
• Permissions the application requires.
• Intent filters that describe how certain components can be launched.
• Application metadata, labels, icons, and themes.
• Device hardware and software features.
• Other configuration information used by Android or distribution platforms.

3.1 Basic Manifest Structure

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android">

    <uses-permission
        android:name="android.permission.INTERNET" />

    <application
        android:allowBackup="true"
        android:label="@string/app_name"
        android:theme="@style/Theme.MyApp">

        <activity
            android:name=".MainActivity"
            android:exported="true">

            <intent-filter>
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>

        </activity>

    </application>
</manifest>

This example declares internet access and a launcher activity. The theme name and other project-specific references must exist in the application. The example does not include every possible manifest element.

4. Understanding Important Manifest Elements

5. Configuring the Application Element

The <application> element defines properties that apply to the application as a whole. It also contains declarations for components such as activities and services.

5.1 Common Application Attributes

5.2 Example Application Configuration

<application
    android:allowBackup="true"
    android:icon="@mipmap/ic_launcher"
    android:label="@string/app_name"
    android:supportsRtl="true"
    android:theme="@style/Theme.MyApp">

    <activity
        android:name=".MainActivity"
        android:exported="true">
        <intent-filter>
            <action android:name="android.intent.action.MAIN" />
            <category android:name="android.intent.category.LAUNCHER" />
        </intent-filter>
    </activity>

</application>

Use resources for user-facing labels and themes. Review backup behavior and other security-related attributes before releasing an application that stores sensitive information.

6. Declaring Activities and Intent Filters

An activity represents a user-facing component of an Android application. Activities must be declared in the manifest unless the relevant component declaration is supplied through a supported build or library mechanism.

6.1 Declaring an Activity

<activity
    android:name=".SettingsActivity"
    android:exported="false" />

This declaration makes the activity available to the application without allowing other applications to launch it directly through normal external component access. Internal navigation can still open it according to the application's implementation.

6.2 Launcher Activity

The launcher activity is the activity that users can open from the application launcher. It commonly uses the MAIN action and LAUNCHER category.

<activity
    android:name=".MainActivity"
    android:exported="true">
    <intent-filter>
        <action android:name="android.intent.action.MAIN" />
        <category android:name="android.intent.category.LAUNCHER" />
    </intent-filter>
</activity>

6.3 Understanding android:exported

The android:exported attribute controls whether a component can be launched by other applications, subject to Android's security rules.

• Set true when the component intentionally needs to be accessible to external callers.
• Set false for components that should remain private to the application or otherwise not be externally launched.
• For apps targeting Android 12 (API level 31) or higher, components that declare intent filters must explicitly specify android:exported.
• Do not expose a component simply to resolve a build error. Consider what external callers could do if they launch it.

7. Declaring Services and Broadcast Receivers

Services and broadcast receivers support specific background and event-driven operations. They should be declared only when needed and configured with appropriate access controls.

7.1 Service Declaration

<service
    android:name=".SyncService"
    android:exported="false" />

This is an illustrative declaration. A service's actual implementation must follow Android's background execution restrictions and the requirements of its intended task. For many scheduled or deferrable background jobs, WorkManager is a more appropriate choice than a continuously running service.

7.2 Broadcast Receiver Declaration

<receiver
    android:name=".MyBroadcastReceiver"
    android:exported="false" />

Declare a receiver in the manifest when appropriate for the event it handles. Some receivers can instead be registered dynamically in code. Do not assume every system broadcast can be received through a manifest-declared receiver on every Android version.

8. Understanding Android SDK Versions

Android SDK version configuration determines which platform APIs are available during compilation, which Android versions can install the app, and which compatibility behaviors apply at runtime.

Developers commonly work with three main values:

• compileSdk: The Android API level used to compile the application.
• minSdk: The minimum Android API level on which the application is intended to run.
• targetSdk: The Android API level whose behavior the application is designed and tested to follow.

9. Difference Between compileSdk, minSdk, and targetSdk

9.1 Compile SDK

The compile SDK specifies the Android platform API level used to compile the application. It can generally be newer than the minimum SDK because the application can be compiled against newer APIs while supporting older devices, provided newer APIs are handled correctly.

9.2 Minimum SDK

The minimum SDK specifies the lowest Android API level the app supports. Setting it too high may exclude users with older devices. Setting it too low requires developers to account for missing APIs and behavior differences on older Android versions.

9.3 Target SDK

The target SDK communicates which Android platform behavior the application is designed for. Newer Android versions may introduce permission changes, restrictions, or other behavior changes that apply based on an application's target level.

Targeting a recent API level helps an application adopt current platform security and privacy expectations. It should be accompanied by compatibility testing, not treated as a value to change without testing.

10. Configuring SDK Versions in build.gradle.kts

In modern Android projects, configure SDK levels in the app module's Gradle build file rather than adding a <uses-sdk> element manually to the manifest. Gradle-generated manifest values take precedence over corresponding manifest declarations.

plugins {
    id("com.android.application")
    id("org.jetbrains.kotlin.android")
}

android {
    namespace = "com.example.myapp"
    compileSdk = 36

    defaultConfig {
        applicationId = "com.example.myapp"
        minSdk = 23
        targetSdk = 36

        versionCode = 1
        versionName = "1.0"
    }
}

The values above are an example configuration, not a universal recommendation. Select SDK levels based on the app's requirements, available tooling, compatibility needs, and current Google Play policies. Ensure the required Android SDK platform and compatible Android Gradle Plugin are installed.

10.1 Groovy Gradle Syntax

Projects using the Groovy DSL can configure these values in build.gradle:

android {
    namespace 'com.example.myapp'
    compileSdk 36

    defaultConfig {
        applicationId 'com.example.myapp'
        minSdk 23
        targetSdk 36

        versionCode 1
        versionName '1.0'
    }
}

Use the syntax appropriate to the build file already used by the project.

11. Understanding API Levels

An API level is an integer identifying a revision of the Android framework API. Developers use API levels to express platform compatibility and determine when an API or behavior became available.

API levels are used here for illustration. Consult the official Android documentation when configuring a real project, particularly when using new platform APIs or preparing an app for publication.

12. Understanding App Permissions

Permissions protect sensitive user data and system capabilities. An application may need permission to access the camera, location, contacts, microphone, or certain other protected features.

Declaring a permission in the manifest does not always mean the permission has been granted. Some permissions are granted automatically under their applicable rules, while others require the user to approve a request at runtime or through a special system settings screen.

12.1 Why Permissions Are Necessary

• To protect personal information and device functionality.
• To give users control over sensitive access.
• To make an application's requested capabilities explicit.
• To ensure that Android can enforce appropriate security checks.
• To communicate permission requirements to Android and app distribution tools.

13. Permission Categories

Permission classification and grant behavior can vary by permission and Android version. Always verify the specific permission's documentation.

14. Declaring Permissions in AndroidManifest.xml

Use the <uses-permission> element to declare a permission that the application needs.

14.1 Internet Permission

<uses-permission
    android:name="android.permission.INTERNET" />

This permission allows the application to open network sockets. It is commonly needed for API requests and remote content. It does not by itself grant permission to use every network-related capability.

14.2 Camera Permission

<uses-permission
    android:name="android.permission.CAMERA" />

Declare camera permission if the application directly accesses the camera through APIs that require it. The app must also handle runtime permission requests where applicable.

14.3 Location Permissions

<uses-permission
    android:name="android.permission.ACCESS_COARSE_LOCATION" />

<uses-permission
    android:name="android.permission.ACCESS_FINE_LOCATION" />

Coarse location supports approximate location access, while fine location can provide more precise location access when authorized and available. Request only the level of precision that the application's feature genuinely needs.

14.4 Microphone Permission

<uses-permission
    android:name="android.permission.RECORD_AUDIO" />

Declare this permission if the application records audio through functionality that requires microphone access. Explain the purpose clearly before requesting access.

14.5 Notification Permission

<uses-permission
    android:name="android.permission.POST_NOTIFICATIONS" />

For apps targeting Android 13 (API level 33) or higher, notification posting generally requires this runtime permission for ordinary notifications. Apps should request it at an appropriate point in the user experience. Platform exceptions may apply to specific notification types or application states.

15. Difference Between Manifest Declaration and Runtime Request

Permission handling often involves two distinct steps: declaring the required permission in the manifest and requesting user approval at runtime when the permission category and Android version require it.

Normal permissions such as INTERNET do not use the same runtime dialog flow as dangerous permissions. Some special access capabilities have separate system settings flows.

16. Requesting Runtime Permissions in Kotlin

For dangerous permissions, use Android's supported permission APIs. The Activity Result API is a convenient approach for many permission requests.

16.1 Example: Requesting Camera Permission

private val requestCameraPermission =
    registerForActivityResult(
        ActivityResultContracts.RequestPermission()
    ) { isGranted ->
        if (isGranted) {
            openCameraFeature()
        } else {
            showCameraPermissionMessage()
        }
    }

private fun requestCameraAccess() {
    requestCameraPermission.launch(
        Manifest.permission.CAMERA
    )
}

This snippet belongs inside an appropriate Android component, such as an activity or fragment, and requires imports for Manifest, ActivityResultContracts, and the related APIs. Implement openCameraFeature() and showCameraPermissionMessage() according to the application's needs.

16.2 Explain the Permission Before Requesting It

Users are more likely to understand a permission request when the application explains why the feature needs access. For example, a camera-based profile-photo feature can explain that camera access is used to take a new profile picture.

• Ask only when the user enters a feature that needs the permission.
• Use a clear explanation when the purpose may not be obvious.
• Respect denial and provide an alternative when possible.
• Do not repeatedly prompt users in a way that disrupts their experience.
• Handle cases where permission has previously been denied or restricted.

17. Handling Permission Denial

Permission denial should not automatically cause the entire application to fail. The app should decide whether the feature can continue without the permission.

For example:

• If camera access is denied, allow image selection from another supported source when possible.
• If location access is denied, let the user manually select a location if appropriate.
• If notification permission is denied, continue to provide the main application functionality without ordinary notifications.
• If a permission is essential to a specific action, explain the limitation and let the user decide what to do next.

Avoid treating permission denial as an application crash or repeatedly displaying the system dialog without considering the user's previous decision.

18. Declaring Device Features

The <uses-feature> element describes hardware or software features used by an application. These declarations can influence app distribution filtering and device compatibility.

18.1 Required Camera Feature

<uses-feature
    android:name="android.hardware.camera.any"
    android:required="true" />

This declaration indicates that the application requires camera hardware. Devices without a matching feature may be filtered out by distribution services that honor the declaration.

18.2 Optional Camera Feature

<uses-feature
    android:name="android.hardware.camera.any"
    android:required="false" />

Use an optional feature declaration when the app can still function without the hardware. The app must check feature availability and disable or adapt camera-dependent functionality when necessary.

Important: A permission declaration and a hardware-feature declaration are not interchangeable. A permission expresses access requirements, while a feature declaration describes hardware or software capabilities.

19. Configuring Network Access Securely

Applications that communicate with remote servers usually declare the internet permission. However, network security also depends on transport encryption, endpoint validation, and platform network security rules.

19.1 Internet Permission

<uses-permission
    android:name="android.permission.INTERNET" />

19.2 Avoid Unnecessary Cleartext Traffic

Prefer HTTPS for production network communication. Do not enable cleartext traffic globally simply to work around a development server configuration problem.

<application
    android:usesCleartextTraffic="false"
    ... >
</application>

Use this setting only after checking the application's network requirements and any network security configuration. Some applications need specialized local development or legacy-network behavior, which should be handled narrowly and deliberately.

20. Understanding Manifest Merging

Android projects can include manifest files from the main app source set, build variants, and library dependencies. During the build, the Android Gradle Plugin merges relevant manifest declarations into the final manifest.

This means the manifest packaged in the APK or App Bundle may differ from the source manifest you initially edited.

20.1 Why Manifest Merging Matters

• Libraries may declare components or permissions required by their functionality.
• Different build variants may need different configuration values.
• Conflicting attributes can produce manifest merge errors.
• The final merged manifest determines the declarations packaged into the app.

20.2 Inspecting the Merged Manifest

1. Open the Android manifest file in Android Studio.
2. Use the Merged Manifest view if it is available for the current project setup.
3. Review the final declarations and their source origins.
4. Resolve unexpected permissions, components, or conflicting attributes.
5. Build and test the application again.

Do not remove a permission from the source manifest without checking whether a dependency requires it and whether the final merged manifest still contains it.

21. Common Manifest and SDK Configuration Errors

22. Best Practices for Manifest and SDK Configuration

• Keep the manifest focused on declarations the application actually needs.
• Configure compileSdk, minSdk, and targetSdk in the module's Gradle configuration.
• Choose a minimum SDK based on actual compatibility and audience requirements.
• Keep the target SDK current with applicable platform and distribution requirements.
• Test the app on both the minimum supported Android version and newer Android versions.
• Declare only the permissions required by real features.
• Request dangerous permissions at runtime where required.
• Explain permission requests in clear, user-friendly language.
• Handle denial and restricted access without crashing.
• Use explicit and secure exported-component settings.
• Check the merged manifest when libraries or build variants affect configuration.
• Prefer encrypted network connections and avoid broad cleartext traffic exceptions.
• Declare hardware as required only when the application truly cannot function without it.
• Review backup, data-sharing, and other security-sensitive application settings before release.
• Use official Android documentation to verify permission-specific and API-specific behavior.

23. Practical Exercise

Exercise: Configure an Android application that displays a list of nearby places and allows the user to open a camera-based photo feature.

Requirements

• Configure the app's namespace, application ID, compile SDK, minimum SDK, and target SDK.
• Declare the launcher activity.
• Add internet permission if the application retrieves place data from a remote service.
• Add appropriate location permissions if the feature genuinely uses device location.
• Add camera permission if the app directly accesses the camera.
• Declare camera hardware as optional if the app can function without a camera.
• Request relevant runtime permissions at the appropriate time.
• Handle permission denial and provide alternative behavior where possible.
• Inspect the merged manifest and verify the final configuration.
• Test the app on an emulator or device with different Android versions.

Example Manifest

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android">

    <uses-permission
        android:name="android.permission.INTERNET" />

    <uses-permission
        android:name="android.permission.ACCESS_COARSE_LOCATION" />

    <uses-permission
        android:name="android.permission.CAMERA" />

    <uses-feature
        android:name="android.hardware.camera.any"
        android:required="false" />

    <application
        android:allowBackup="true"
        android:label="@string/app_name"
        android:theme="@style/Theme.MyApp">

        <activity
            android:name=".MainActivity"
            android:exported="true">

            <intent-filter>
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>

        </activity>
    </application>
</manifest>

This example is a learning template. Remove any permission that the application does not actually need, confirm the theme and activity names, and implement the appropriate runtime permission flow. A location permission declaration alone does not provide the location feature's implementation.

24. Interview Questions and Answers

Q1. What is AndroidManifest.xml?

Answer: It is a configuration file that describes essential application information, including components, permissions, and other settings used by Android build tools and the operating system.

Q2. What is the purpose of the application element?

Answer: The <application> element contains application-level properties and declarations for components such as activities, services, and receivers.

Q3. What is the difference between compileSdk and minSdk?

Answer: compileSdk selects the API level used to compile the app. minSdk defines the minimum API level the app supports.

Q4. What is targetSdk?

Answer: It specifies the API level whose Android platform behavior the application is designed and tested to follow. It can affect compatibility behavior and platform requirements.

Q5. What is a runtime permission?

Answer: It is a permission that the application must request from the user at runtime when required by Android's permission model.

Q6. Does declaring a permission mean that the user has granted it?

Answer: No. Dangerous permissions generally require a runtime grant where applicable, and special access permissions may require a separate settings flow.

Q7. What is the purpose of android:exported?

Answer: It specifies whether a component is available for launching by other applications, subject to Android's security rules.

Q8. What is the difference between a permission and a uses-feature declaration?

Answer: A permission describes access to a protected capability. A feature declaration describes a hardware or software capability that an application uses or requires.

Q9. Why is INTERNET permission commonly required?

Answer: It allows the application to open network sockets for communication with remote services. It does not replace other security or authentication requirements.

Q10. What is manifest merging?

Answer: Manifest merging combines relevant declarations from the app, build variants, and library dependencies into the final manifest packaged with the application.

Q11. Why should developers avoid unnecessary permissions?

Answer: Unnecessary permissions increase privacy risks, complicate permission handling, and may reduce user trust.

Q12. Why should SDK versions be tested carefully?

Answer: SDK choices affect device compatibility, API availability, and platform behavior. Testing helps identify crashes and behavior changes across supported Android versions.

Q13. What happens when minSdk is higher than a device's API level?

Answer: The device generally cannot install the application because it does not meet the application's minimum platform requirement.

Q14. How should an app handle a denied camera permission?

Answer: It should avoid accessing the camera, explain the limitation when appropriate, and offer an alternative if the feature can reasonably continue without camera access.

Q15. Why should developers inspect the merged manifest?

Answer: Libraries and build variants can add or change manifest declarations. Inspecting the merged result helps identify unexpected permissions, component settings, and merge conflicts.

25. Quick Revision Checklist

• Understand the purpose of AndroidManifest.xml.
• Know the roles of <manifest> and <application>.
• Understand activities, services, receivers, providers, and intent filters.
• Know why explicit android:exported values matter.
• Distinguish compile SDK, minimum SDK, and target SDK.
• Configure SDK levels in Gradle.
• Understand the difference between declaring and granting a permission.
• Request runtime permissions where required.
• Handle denied permissions gracefully.
• Use <uses-feature> to describe hardware requirements correctly.
• Inspect the merged manifest for unexpected entries.
• Test compatibility and permission flows on multiple Android versions.

26. Conclusion

Configuring manifest entries, SDK versions, and app permissions is essential for building Android applications that install correctly, behave predictably, and respect user privacy. The manifest declares important components and application capabilities, SDK settings determine compatibility and target behavior, and permissions govern access to protected features and information.

Developers should select SDK levels deliberately, declare only necessary permissions, request sensitive access at appropriate moments, and test their applications across supported Android versions. By following these practices, Android developers can build more secure, compatible, and reliable applications.

27. Additional Learning Resources

• Android Developers: App Manifest Overview
• Android Developers: SDK Version Configuration
• Android Developers: Request App Permissions
• Android Developers: Declare App Features
• Google Play: Target API Level Requirements
• Explore the Android App Development Course at JustAcademy
• Register for a JustAcademy Course Demo
• Visit the JustAcademy Website